REMARKS 

The Office Action dated May 22, 2 0 09, has been received and carefully noted. 
The above amendments to the claims, and the following remarks, are submitted as a full 
and complete response thereto. 

Claims 1 and 24-6 1 are currently pending in the application, of which claims 1 and 
24-27 are independent claims. Claims 1 and 24-25 have been amended to more 
particularly point out and distinctly claim the invention. Claims 62-63 have been 
cancelled without prejudice or disclaimer. No new matter has been added. Claims 1 and 
24-61 are respectfully submitted for consideration. 

The Office Action objected to claims 62-63 under 35 CFR § 1.75(c) as allegedly 
being of improper dependent form for failing to further limit the subject matter of a 
previous claim. Claims 62-63 have been cancelled without prejudice or disclaimer. 
Withdrawal of the objection as moot is respectfully requested. 

The Office Action rejected claims 1, 24-27, 29-30, 43-44, and 57-58 under 35 
U.S.C. § 103(a) as being allegedly unpatentable as obvious over U.S. Patent No. 
6,219,697 of Lawande et al ("Lawande"). The Office Action acknowledged that not all 
of the claim features are disclosed by Lawande, but asserted that the remaining features 
would have been obvious. Applicant respectfully traverses this rejection. 

Claim 1 is directed to a system including a port connector and a plurality of 
modules configured to communicate data between each other through the port connector. 
The modules are configured to communicate a data package comprising in a layered 
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structure a physical layer including a first and a second segment to encapsulate other 
layers in said data package, a data link layer comprising a first header field for data 
payload type and a second header field for a data link layer version, and a 
network/transport layer comprising a third header field for a transmitting module's 
address, a fourth header field for a length of said data package, a fifth header field for an 
offset value for determination of data payload start in said data package, and comprising 
data payload. 

Claim 24, upon which claims 28-41 depend, is directed to an apparatus including 
at least one memory including computer program code and at least one processor. The at 
least one memory and the computer program code are configured to, with the at least one 
processor, cause the apparatus at least to receive a data package configured to be 
communicated between modules connected through a port connection. The data package 
includes, in a layered structure, physical layer data comprising a first and a second 
segment to encapsulate other layers in said data package, data link layer data in a first 
header field comprising data payload type and in a second header field comprising a data 
link layer version, and network/transport layer data in a third header field comprising a 
transmitting module's address, in a fourth header field comprising a length of said data 
package, in a fifth header field comprising an offset value for determination of data 
payload start in said data package, and comprising data payload. 

Claim 25, upon which claims 42-61 depend, is directed to an apparatus including 
at least one memory including computer program code and at least one processor. The at 
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least one memory and the computer program code are configured to, with the at least one 
processor, cause the apparatus at least to transmit a data package configured to be 
communicated between modules connected through a port connection. The data package 
comprises, in a layered structure, physical layer data comprising a first and a second 
segment to encapsulate other layers in said data package, data link layer data in a first 
header field comprising data payload type and in a second header field comprising a data 
link layer version, and network/transport layer data in a third header field comprising a 
transmitting module's address, in a fourth header field comprising a length of said data 
package, in a fifth header field comprising an offset value for determination of data 
payload start in said data package, and comprising data payload. 

Claim 26, upon which claims 56-61 depend, is directed to a method including 
establishing, by a transmitter, data communication between modules connected through a 
port connection, wherein said modules each communicate a data package comprising in a 
layered structure a physical layer comprising a first and a second segment to encapsulate 
other layers in said data package. The establishing includes providing, in said data 
package, in a data link layer, a first header field for data payload type and a second 
header field for a data link layer version. The establishing also includes providing, in 
said data package, in a network/transport layer, a third header field for a transmitting 
module's address and a fourth header field for a length of said data package and a fifth 
header field for an offset value for determination of data payload start in said data 
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package. The establishing further includes providing, in said data package, a data 
pay load. 

Claim 27 is directed to a computer program embodied on computer-readable 
storage medium and comprising code configured to perform a process when said program 
is run in a processor. The process includes establishing data communication between 
modules connected through a port connection, wherein said modules each communicate a 
data package comprising in a layered structure a physical layer comprising a first and a 
second segment to encapsulate other layers in said data package. The establishing 
includes providing, in said data package, in a data link layer, a first header field for data 
payload type and a second header field for a data link layer version. The establishing 
also includes providing, in said data package, in a network/transport layer, a third header 
field for a transmitting module's address, a fourth header field for a length of said data 
package, and a fifth header field for an offset value for determination of data payload 
start in said data package. The establishing further includes providing, in said data 
package, a data payload. 

Applicant respectfully submits that Lawande fails to disclose or suggest all of the 
elements of any of the presently pending claims. 

Applicant respectfully submits that the Office Action has attempted to identify 
corresponding elements, for those of claim 1 , in Lawande by selecting features of any 
elements without consideration for the factual association described in the description. 
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This is improper, as both the claims and the references must be considered as a whole, 
and the claims must be read in light of the specification. 

Certain embodiments of the present invention involve the provision of a number of 
fields within the header of the transported packet, such as an IP, or OBEX type packet, 
where (on the other hand) Lawande discusses the provision of fields in the header of the 
enveloping layer IEEE 1394. 

The Office Action responded by noting that "IP" and "OBEX type" are not found 
in the claims. However, Applicant respectfully submits that the context of the application 
provides light on the claims, as the Office Action admitted: "the claims are interpreted in 
light of the specification" (Office Action, page 9). Thus, the discussion in the 
specification must not be ignored in properly construing the claims, and the discussion in 
the specification places boundaries on what the broadest reasonable interpretation of the 
claims is. 

From Figure 5 of Lawande it is evident that the IP packet is provided on a 
different layer than the Common Packet Header (CPR), which is a part of the IEEE link 
layer, as that term would be understood to one of ordinary skill in the art. Furthermore, 
in column 17, in Lawande, it is stated that the protocol IEEE 1394 "has a field in the 
header which has memory information of the target of the packet of the data." However, 
to integrate the two protocols, the field is modified , putting in the "protocoltype" field in 
the packet header. 
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Hence, it is clearly shown that the "protocoltype" field according to Lawande is 
located in the header of the IEEE 1394 protocol, whereas the "data payload type" field 
according to certain embodiments of the present invention is located in the header of the 
transported packet, or (more specifically) the data segment. This is further supported in 
the description portion of the present application on page 15, lines 18- 21 : "in this context 
when referring to a header section, the header section of the data segment is meant unless 
specifically stated otherwise." Accordingly, Lawande does not disclose a protocol type 
identifier in the header of the encapsulated data segment. 

In response to the above, the Office Action stated disagreement and reiterated a 
portion of the rejection verbatim, neither of which is a response that advances 
prosecution, since Applicant has already explained the deficiencies of the rejection as 
stated. 

In addition, the Office Action stated: "the claim recites a data link layer 
comprising the data payload type, constituting the IEEE 1394 link layer comprising the 
protocol type in Lawande." However, it is unclear how this is supposed to address the 
distinctions identified above, since it seems simply to be a conclusory assertion that the 
mapping in the claims is proper. 

More specifically, certain embodiments of the present invention relate to the 
provision of a "data payload type" field in the header of the data segment encapsulated in 
between the two segments of the physical layer referred to in claim 1 and shown (in one 
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embodiment) as 12a and 12b in Fig. la. This, however, is not reflected in fig. 7c in 
Lawande, because Lawande does not disclose what is recited in claim 1 . 

Lawande, furthermore, would not lead one of ordinary skill in the art toward the 
claimed invention. Lawande has been considered (by the USPTO) as the closest prior art, 
since it allegedly has some elements in common. The objective problem to be solved by 
a person of ordinary skill in the art in light of Lawande could be characterized as follows: 
How to integrate IEEE 1394 protocols with IP protocols. A person of ordinary skill in 
the art facing this problem could perhaps, in light of Lawande, know how to integrate a 
IEEE 1394 protocol with IP protocols. 

It would not, however, be obvious for a person of ordinary skill in the art to 
provide a header of a data segment with a field specifying the content of said specific 
data segment. More specifically, certain embodiments of the present invention relate to 
the provision of backward and forward compatibility of a data link layer protocol in a 
system of connecting modules through a port connection. Further, another object of 
certain embodiments of the present invention relate to the way of managing packets of a 
number of different protocols simultaneously. These objects (nor any similar) cannot be 
found in the cited art. Thus, the cited art would not lead one of ordinary skill in the art 
toward the claimed invention. 

The Office Action responded by noting that "backward and forward compatibility" 
and "way of managing packets of a number of different protocols simultaneously" are not 
found in the claims. However, Applicant respectfully submits that the advantages of 
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certain embodiments of the present invention do not have to be recited to provide 
evidence of non-obviousness. Thus, the advantages must not be ignored in properly 
assessing the non-obviousness of the claims, and the discussion of the advantages 
provides evidence that would rebut a prima facie case of obviousness, if such had been 
presented (not admitted). 

The Office Action also repeated a portion of the rejection and pointed out that the 
alleged mapping between Lawande and the claims is between the claimed physical layer 
and the physical layer of Lawande. The Office Action also stated, "An alternate 
interpretation is that the physical layer is formed by data from the upper layers, and 
Lawande discloses the format of IP packet together with the IEEE 1394 layer, thus 
forming first and second segments at the physical layer." It is unclear why the Office 
Action has taken the position that something other than the physical layer of Lawande 
should alleged correspond to the physical layer of the present claims. To the extent that 
this alternative ground is relied upon, it is respectfully submitted that it requires reading 
the claims in an unreasonably broad way. 

Additionally, Lawande does not disclose "an offset value for determination of data 
payload start in said data package, 55 as recited in (for example) claim 1 . According to the 
description of the present application, on page 5, line 28, to page 6, line 3, the offset 
value can provide means for compensating for future changes to the network/transport 
protocols, since the receiving module (through the offset value) may jump directly to the 
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payload start when the receiving module does not require the potential data from the 
header. 

Furthermore, according to the description of the present application on page 18, 
lines 20-28, the offset field can be incorporated in the header section to make the header 
backward compatible. When future fields are added to the header, any software can 
forward payload data even though the software is aware of the additional fields, since the 
software may forward the data package based on the Offset and the Version field. Hence, 
this field can permit compensation for future extensions of the header section, as there 
might be a need in the future for additional fields in the header. These extensions can be 
added while still being backward compatible, the Offset field will tell the receiving entity 
where the actual data package starts. 

In contrast to the above, and in contrast to the feature "an offset value for 
determination of data payload start in said data package," the common packet header in 
Fig. 7C of Lawande contains a destination offset field in order to comply with the IEEE 
1394's requirement of including memory architecture information. However, the 
reference to ip_fragment__offset in Lawande is a part of the IP protocol, which has to do 
with fragmenting a large non-IP packet into several, smaller IP packets. More 
specifically, to fragment a datagram, the header size is used to calculate how many 
fragments are required. The header of the original datagram is then copied into the 
headers of each of the fragments. The fragment offset reflects the position of the 
fragment within the original datagram. Each fragment becomes its own datagram and is 
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routed independently of any other datagrams. This makes it possible for the fragments of 
the original datagram to arrive at the final destination out of order. At the final 
destination, the fragment offset field tells the receiver how to order the fragments. 
Hence, the concept of the Offset field according to the discussion in the present 
application's specification (and recited in claim 1: "an offset value for determination of 
data payload start in said data package") is not disclosed in Lawande. 

Indeed, in Lawande there is nothing that would lead a person skilled in the art 
closer in respect of using an offset field in the way it is used according to the present 
claims. Furthermore, the solution according to Lawande may have a number of 
drawbacks. Firstly, the protocoltype field is multiplexed with the memory information 
field, making it complex when decoding the field. Secondly, the solution according to 
Lawande renders it difficult or impossible to mix different protocol types in the same 
connection. Lawande is specifically designed for transfer of IP messages, whereas 
certain embodiments of the present invention allow a combination of multiple protocols 
sent simultaneously on the same connection without resetting or changing its state. For 
instance, OBEX and IP packages can be sent alternating in respect to each other without 
resetting the connection. 

The Office Action, at pages 15-16 responded similarly to the previous responses, 
and the Office Action's responses have similar flaws. In particular, the Office Action 
insisted that one of ordinary skill in the art would have found it obvious "to use an offset 
field similar to the fragment offset field, e.g., the payload offset field, to determine the 
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start of the payload. Thus Lawande discloses "an offset value for determination of data 
payload start in said data package/' as claimed" (Office Action, page 16). Applicant 
respectfully disagrees. 

First, Lawande does not disclose "an offset field similar to the fragment offset 
field.' 5 Lawande specifically mentions "ip_fragment_offset" and does not suggest or in 
hint in the least that any variation at all to this field is either possible or desirable. 
Accordingly, Lawande does not fairly disclose or suggest using "an offset field similar to 
the fragment offset field." 

Second, Lawande's "ip_fragment_offset" or anything like it would not correspond 
to the "an offset value for determination of data payload start in said data package," as 
recited in (for example) claim 1 . The ip_fragment_offset field identifies an offset, but it 
is not an offset that expresses a relationship within the packet itself. The offset expressed 
by ip_fragment_offset is an offset of the content of the fragment with respect to an 
original packet upon which the fragment is based. This could be called an 
"inter-package" offset. 

In contrast, the offset recited in the claim is an offset that is expressed with respect 
to the data package that contains the offset field. Thus, this could be called an 
"intra-package" offset. Thus, the two different kinds of offsets ( inter -package offset and 
intra-package offset) have completely different functions and roles in the packet. 
Accordingly, it would not be obvious to one of ordinary skill in the art to change one kind 
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of offset into the other, because doing so would fundamentally alter the operation of the 
field. 

Specifically, if one made the ip_fragment_offset field into an offset that 
determined "data payload start in said package " (as contrasted with the payload start in 
an original packet from which the package is derived as in the ip_fragment_offset 
instance), then the ip_fragment_offset field would not work properly, since it would not 
permit the reassembly of a fragmented original packet, which is what its purpose is in 
Lawande. 

Such a change, therefore, would necessarily render Lawande inoperable for its 
intended purpose. MPEP 2143.0 1(V) states "THE PROPOSED MODIFICATION 
CANNOT RENDER THE PRIOR ART UNSATISFACTORY FOR ITS INTENDED 
PURPOSE," (Capital letters in original.) and explains that "If proposed modification 
would render the prior art invention being modified unsatisfactory for its intended 
purpose, then there is no suggestion or motivation to make the proposed modification." 
Moreover, MPEP 2145(VI) states that "the claimed combination cannot change the 
principle of operation of the primary reference or render the reference inoperable for its 
intended purpose." Thus, in this case, since the proposed modification to Lawande's 
ip_fragment_offset would render Lawande inoperable for its intended purpose, such a 
modification is per se non-obvious. 

The Office Action further argued that "using a field in a message to determine the 
start of payload is well known in the art" and cited U.S. Patent No. 5,937,169 of Connery 
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et al ("Connery") as allegedly supporting this contention. However, as is plain from 
Figure 4 of Connery, the "data offset field" of Connery is in the TCP header, while the 
"fragment offset" (corresponding to Lawande's "ip_fragment_offset") is found in the IP 
header of Connery. Thus, Connery does not provide motivation to modify Lawande's 
"ip_fragment_offset" into a "data offset" as shown in Figure 4 of Connery, nor into the 
claim features. 

Furthermore the proposed motivation to modify Lawande is plainly erroneous. 
The Office Action stated that the reason for the modification would be "in order to 
quickly identify the start of the payload and thus effectively perform packet processing." 
This motivation is fundamentally flawed. Lawande is presumptively already able to 
perform packet processing. If packet processing could not be performed on Lawande's 
packets without further modification, then Lawande would not be enabled, but U.S. law 
presumes that granted patents are enabled. 

Furthermore, adding an additional field to Lawande would not be expected to 
enhance the speed of finding the start of the payload in Lawande. Lawande's structure as 
illustrated in Figure 7C requires that the payload starting point in Lawande is always the 
same and therefore already known a priori to the processing system. Adding a data field 
that conveyed already known information would be against common sense. Thus, it 
would not have been obvious to one of ordinary skill in the art to include such a field in 
Lawande's structure. Therefore, it is respectfully maintained the rejection is improper 
and should be withdrawn. 
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Hence, for all the preceding reasons, it is respectfully submitted that the subject- 
matter of the claimed invention in claim 1 is not obvious in view of Lawande. Although 
each of the independent claims has its own unique scope, the same reasoning as for 
independent claim 1 is also valid for each of independent claims 24-27, as they contain 
corresponding features to those discussed above, with respect to claim 1. Thus, it is 
respectfully requested that each of the rejections of each of claims 1 and 24-27 be 
withdrawn. 

Claims 29-30, 43-44, and 57-58 depend respectively from, and further limit, 
claims 24-26. Thus, each of claims 29-30, 43-44, and 57-58 recites subject matter that is 
neither disclosed nor suggested in Lawande. It is, therefore, respectfully requested that 
the rejection of claims 29-30, 43-44, and 57-58 be withdrawn. 

The Office Action rejected claims 28, 42, and 56 under 35 U.S.C. § 103(a) as being 
allegedly unpatentable as obvious over Lawande in view of U.S. Patent No. 5,572,528 of 
Shuen ("Shuen"). The Office Action acknowledged certain deficiencies of Lawande with 
respect to the rejected claims and cited Shuen to remedy such deficiencies. Applicant 
respectfully traverses this rejection. 

Claims 28, 42, and 56 depend respectively from, and further limit, claims 24-26. 
Thus, each of claims 28, 42, and 56 recites subject matter that is neither disclosed nor 
suggested in Lawande. Shuen does not remedy the deficiencies of Lawande. 

Shuen generally relates to a mobile networking method and apparatus. Thus, for 
this reason, as well as because Shuen was cited only as to features of the dependent 
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claims, it is unsurprising that Shuen fails to remedy the above-identified deficiencies of 
Lawande. Therefore, the combination of Lawande and Shuen fails to disclose or suggest 
all of the elements of the rejected claims and it is respectfully requested that the rejection 
of claims 28, 42, and 56 be withdrawn. 

The Office Action rejected claims 31-41, 45-55, and 59-63 under 35 U.S.C. 
§ 103(a) as being allegedly unpatentable as obvious over Lawande in view of U.S. 
Publication No. 2003/0214928 of Chuah ("Chuah"). The Office Action acknowledged 
certain deficiencies of Lawande with respect to the rejected claims and cited Chuah to 
remedy such deficiencies. Applicant respectfully traverses this rejection. 

Claims 31-41, 45-55, and 59-63 depend respectively from, and further limit, 
claims 24-26. Thus, each of claims 31-41, 45-55, and 59-63 recites subject matter that is 
neither disclosed nor suggested in Lawande. Chuah does not remedy the deficiencies of 
Lawande 

Chuah generally relates to a method for paging a device in a wireless network. 
Thus, for this reason, as well as because Chuah was cited only as to features of the 
dependent claims, it is unsurprising that Chuah fails to remedy the above-identified 
deficiencies of Lawande. Therefore, the combination of Lawande and Chuah fails to 
disclose or suggest all of the elements of the rejected claims and it is respectfully 
requested that the rejection of claims 31-41, 45-55, and 59-63 be withdrawn. 

For the reasons set forth above, it is respectfully submitted that each of claims 1 
and 24-61 recites subject matter that is neither disclosed nor suggested in the cited art. It 
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is, therefore, respectfully requested that all of claims 1 and 24-61 be allowed, and that 
this application be passed to issuance. 

If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, Applicant's undersigned representative at the indicated telephone number to 
arrange for an interview to expedite the disposition of this application. 

In the event this paper is not being timely filed, Applicant respectfully petitions for 
an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 
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